Network operators in general, and mobile operators in particular, are presently offering a wide range of services to their users and, very often, these services are actually provided by external service providers (SP). Thus, a network operator is acting as a virtual service provider for its users and charges them appropriately for the use of services, whereas external service providers actually provide said services and generate charging accounts to the operator for the provision of their services. Such network operator acting as a service provider for its users is hereinafter referred to as a Service Network Operator (SNO).
In this situation, a first domain represented by the SNO network is responsible for authenticating a user requesting a service, as well as for authorising the user accessing the requested service. This service being actually provided by a second domain owned by an external service provider likely having a commercial relationship with the network operator, but both domains likely owned by separate companies.
A currently known initiative supporting the above scenario is the Ericsson Service Delivery Platform (hereinafter referred to as ESDP) aimed to help the network operators to offer access-independent services to their subscribers. Generally speaking, ESDP considers that a subscriber accesses to services available in a Service Network via an industrially called “http reverse-proxy”. Under this known approach, the user is authenticated in an Authentication-Authorisation-Accounting (AAA) server and, because of this authentication procedure, a master session is created. A master session typically includes information about the type of access, user identifiers, authentication mechanism to make use of, time of session establishment, etc. An active master session guarantees that the user is authenticated. However, the master session has no information about the services being used by the user. Thus, whenever a user tries to access a service in its profile, the master session is checked to determine whether the user had been authenticated before authorising the service.
This ESDP, as well as other known platforms in the industry, supports what has been generally referred to as Single Sign-On functionality, by virtue of which, a user accessing the SNO network through a trusted access network is authenticated just once to become authenticated for all services offered by the Service Network Operator (SNO).
For example, an exemplary scenario occurs when the trusted access network is a packet radio network like a General Packet Radio Service (GPRS) network and the user is assigned a Gateway GPRS Support Node (GGSN) for getting connectivity with a service network operator (SNO) domain.
In this scenario, the support for Single Sign-On (SSO) services is based on a so-called ‘MSISDN forwarding’ mechanism, wherein MSISDN traditionally stands for Mobile Subscriber ISDN Number though, in a broader sense, it can be assumed as a subscriber directory number. In brief, the ‘MSISDN forwarding’ mechanism is initiated from a Gateway GPRS Support Node (GGSN) in a home core network domain by sending a RADIUS Access Request message, which includes an MSISDN and an IP address for the user, towards an ‘Authentication, Authorisation and Accounting’ (AAA) server in the home service network domain. This information allows the AAA server to create a master session for the user so that whenever said user requests access to a service, the master session is checked to confirm that the user is already properly authenticated. More particularly, the international application with publication number WO 01/67716 A1 describes an ‘MSISDN forwarding’ mechanism based on a RADIUS Accounting Start message that can be applied under some scenarios. This international application describes features for supporting Single Sign-On and thus authenticating the user just once under some particular circumstances.
However, with regard to service authorisation, when a user has been authenticated once under the SNO network, the user is transparently granted the right to launch any provisioned service. Thus, once a service is authorised, the service network operator looses the control over the service. That is, the service network operator can not control any longer the progression of the service, is not aware of the actions carried out by the parties involved during the execution of the service, and can not take any action during this execution, such as disconnection of the service session to avoid a fraudulent misuse of the service.
A currently existing mechanism to authorize a service for a user, which is illustrated in FIG. 1, starts when the user issues a service request towards an access network, which in particular may be a GPRS network, being a GGSN the specific GPRS node receiving such request. The receiver sends this service request towards an Application Gateway Module (AGM) of the service network that is generally in charge of intercepting application messages between the user and the service, and identifying said user and said service. This Application Gateway Module (AGM), which in particular might be the above “http reverse-proxy”, is conventionally provided with means for obtaining an authorization decision from a so-called Authorisation Module (AM) on whether or not the user is allowed to access the service. This Authorisation Module (AM), which in particular might be the above AAA server, is generally in charge of deciding whether or not a user is authorised to access a service depending on a number of conditions. Both entities, the Application Gateway Module and the Authorisation Module, can be provided in respective standalone mode or integrated with other entities, in particular both can be integrated in a same entity.
Nevertheless, the existing mechanisms are still valid for most of the nowadays existing services based on a request and an answer, such as requesting a ring melody and the download of said ring melody, but for more sophisticated transactional services, for instance services that include respective sequences of associated sub-services, the existing techniques present the above serious limitations for the operators to fully control the progression of services.
One simple solution for transactional services may be achieved by forcing any transaction between user and service to be authorised regardless any previous authorisation. However, this potential solution would hugely overload any traffic model and can be thus regarded as an additional drawback to solve.
On the other hand, given that the service network operator (SNO) does not realise when different transactions of a service take place, the service network operator can not be aware of the different actions carried out by the parties, namely user and service, and can not apply specific policies depending on such different actions. Moreover, the service network operator (SNO) cannot even disconnect a user in real time from using a service once the user is authorised to do so.
Thereby, an important object of the present invention is the provision of means and methods to control the progression of a service at a first domain where the service has been authorised while the user is using said service provided by a second domain.
It is a further object of the present invention to achieve a suitable solution wherein such control includes a further verification mechanism for verifying the use of the service.